An increasing use of communications networks is for content delivery to customer premises by service providers. For example, service providers may operate hybrid fiber/coax plants with network controllers at managed locations, such as a headend or fiber node. Access Networks based on the MoCA (Multimedia over Coax Alliance) 2.0 protocol are one type of network used for such content delivery system. FIG. 1 illustrates a network topology for an access network. In this network, a network controller 101 is in communication with a plurality of network nodes 103. For example, the network controller 101 may be an Access Network Controller (NC) (sometimes referred to as a Network Coordinator) managed by an Operator/Service Provider (OSP) or Multiple System Operator (MSO), such as a cable company. The network nodes 103 may comprise various Customer Premise Equipment (CPEs), such as televisions, computers, high-speed data modems, set-top boxes, or other network connected content delivery systems. The Access Network is arranged in a point-to-multipoint topology 102. In the point-to-multipoint topology, the network nodes 103 communicate with the NC 101 and the NC 101 communicates with each node 103, but the nodes 103 do not communicate with each other. In Access Networks, hundreds of CPEs can be in communication with a single NC. Other implementations of the MoCA standard involve in-home networks (HNs). MoCA HNs use mesh topologies with multipoint-to-multipoint topologies, where any node can communicate with any other node. MoCA HNs are usually 16 nodes or fewer, including the NC.
In an access network, downstream traffic is transmitted from the NC 101 to one, some, or all of the CPEs. Upstream traffic is transmitted from CPEs to the NC. Upstream traffic is generally transmitted one CPE at a time (sometimes called upstream bursts). When the NC 101 has information (sometimes referred to as “datagrams”) to send to CPEs, it can simply schedule and transmit such downstream traffic. Accordingly, little or no preparation and interaction is required between NC 101 and the destination nodes 103 (or CPEs). However, upstream bursts require more preparation and interaction between the nodes 103 and the NC 101 in order for the NC 101 to properly schedule traffic. Datagrams that originate at the CPE are destined for the NC 101 (e.g., for processing by the NC 101, or for relay onto the internet, . . . ). When a CPE has data to send, the CPE must inform the NC 101 and wait for an upstream transfer to be scheduled.
In MoCA networks, access to the medium is controlled by the NC 101. The NC 101 divides the transmission time into units referred to as Media Access Plan (MAP) cycles. The NC 101 schedules transmission during the MAP cycles. FIG. 2 illustrates such MAP cycles 203, 205. Each MAP cycle 203, 205 is divided into time slots. During each MAP cycle 203, 205, the NC transmits a MAP packet 201, 202 that provides a schedule to all the network nodes indicating when, within the next MAP cycle, each packet (including the next MAP packet 202) will be sent. Networks may apply other scheduling methods as well. For example, the NC 101 may send individual (e.g., unicast) grants to each node or CPE 103.
FIG. 2 is a timing diagram that illustrates the timing relationship between MAPs 201, 202 and MAP cycles 203, 205. MAP 201 indicates the allocation of time slots within MAP cycle 205. Accordingly, each MAP 201 schedules all of the communication activity for the next MAP cycle 205 (including any communication that originates with the NC). Only one such “next MAP cycle” 205 is shown in FIG. 2, however, it should be understood that MAP 202 schedules all communications for the MAP cycle (not shown) that follows MAP cycle 205.
Reservation requests (RR) 207, 209, 211 are one particular type of packet that the MAP 201, 202 is responsible for scheduling. Six such RRs 207, 209 are shown in the first MAP cycle 203 of FIG. 2, starting with the first RR 207 and ending with the last RR 209. One RR 211 is shown in the second MAP cycle 205. Each RR 207, 209 is sent from one node 103. Each RR 207, 209 may contain one or more Reservation Request Elements (RREs). Each RRE communicates a desire on the part of the node 103 from which the RR 207, 209 was sent to transmit one MoCA packet. The RR 207, 209 allows a client node 103 to communicate to the NC 101 that the client node 103 has data packets it wishes to send. Furthermore, the RR 207, 209 indicates the packet length (from which the packet duration can be determined), packet priority, Flow ID and so on for those data packets. The NC 101 uses this information to schedule “transmission slots” during which the client node 103 can transmit those data packets it wishes to send. The NC 101 then communicates that schedule by generating and transmitting the MAP 201. The MAP 201 includes transmission slot assignments for the next MAP cycle 205.
During a “data packet transmission phase”, an RR 207, 209 is either “granted” (i.e., scheduled) or discarded by the NC. The RR is granted depending on whether there is sufficient network bandwidth to service the request. It should be noted that for the purpose of this description, “granted” means that the NC 103 assigns a transmission slot to the packet associated with the RR 207 to allow the node that generated the request to transmit the associated packet during the assigned transmission slot in the next MAP cycle 205. The NC then transmits a MAP 201 to indicate the schedule to all of the nodes 103 of the network, including the requesting node. Each requesting node 103 then transmits the packets in MAC cycle 205 according to the schedule indicated by the MAP 201.
Network nodes 103, for example, customer premise equipment (CPEs), must inform the network controller 101 (or other such scheduler) when they have traffic to send upstream. For example, a notification may be needed when a new service flow starts up. A notification may also be required during existing flows if they have sparse or asynchronous transmissions. Currently, these notifications are transmitted in small packets, such as EPON Report messages, or MoCA Reservation Requests sent to the scheduler. Accordingly, large service groups that comprise several CPEs can generate a large number of small packets that are latency-sensitive (i.e., that can be adversely affected by a long latency).
The overhead required to transmit information (e.g., preambles, etc.) can limit the performance of a network when several small packets are transmitted. Ordinarily, small packets can be aggregated to create larger transmissions. Aggregation can mitigate the effects of the overhead that would otherwise be required to send the smaller packets. However, it is not desirable to aggregate small traffic notification packets because of the latency that occurs when aggregating packets. In some cases, if a CPE has already established an upstream flow, the traffic notification packets can be piggybacked on that flow. Otherwise, these requests need to be transmitted individually from each CPE.
Additionally, each upstream burst transmission includes a preamble before the payload. The preamble is generally included to allow the receiving node to synchronize itself to the transmission before the payload arrives. The preamble is substantial in length (e.g., 5˜15 μs, or 1˜3 symbol periods in duration). The preamble represents overhead because there is no user data being transferred during that period. This overhead is substantial, and is an even larger percentage for small payloads. Small packets (e.g., 64˜100 byte payloads) make up the bulk of upstream traffic in access networks. For example, RRs 207, 209 are small packets. Every node or CPE 103 must regularly (e.g., every 1˜2 milliseconds) transmit an RR 207, 209 to the NC 101. RRs 207, 209 must be scheduled and sent even when there is no data at the node or CPE awaiting scheduling (the NC does not know if there is data waiting or not, so it must schedule an RR to find out). This periodic transmission of RRs to discover if traffic needs to be scheduled is sometimes called “polling.” The polling of all the nodes is sometimes called an “allocation cycle”.
When there are a large number of nodes or CPEs in the network, then there are a large number of RRs that need to be sent to the NC. Not all nodes or CPEs are actively being used at any given time. For example, in access networks, it is possible that only 10% of subscribers are home and have their equipment in use at a given time. Nevertheless, these inactive CPEs are often polled in the allocation cycle because they may become active at any time and regular polling is the way the NC can know when a CPE has data to transmit. Other packets that are also both small and latency sensitive include TCP ACK acknowledgements, Voice-over-IP (VoIP) packets, interactive gaming messages, and the like.
The transmission of large numbers of small packets that cannot be aggregated can cause congestion and slow the pace of polling of all the CPEs. MoCA's MAP Cycle is similar to an allocation cycle (it is desirable for the NC to grant an RR to each node or CPE in each MAP Cycle). However, with a large number of nodes or CPEs it becomes difficult or unaffordable to fit RRs for every node or CPE (and their overhead) into the MAP cycle. Consequently, the NC may decide that some nodes or CPEs cannot be granted an RR every MAP Cycle. When the polling interval or allocation cycle gets long (e.g., due to inefficiencies and/or large service groups), the network latencies get long as well.